this could be simplified with v11 thanks to the new representation of untagged variants that will allow Nullable.t to be defined like this:

module Nullable = {
  @unboxed type t<'a> = Present('a) | @as(null) Null | @as(undefined) Undefined
}

Then those utility functions could be replaced with a simple pattern matching.

It's not related to the post, but I've just thought of a possible problem that Nullable.t<Nullable.t<string>> like Present(Null) is matched as Null which might cause problems. Maybe not a big problem since it wasn't working before as well. But to make it work correctly and improve DX I think that @unboxed types should collapse like Nullable.t<Nullable.t<string>>->Nullable.t<string>

So maybe we should recover the @cristianoc's idea from some time ago? https://forum.rescript-lang.org/t/rfc-automatic-optional-chaining/3791/17?u=dzakh

It's not related to the post, but I've just thought of a possible problem that Nullable.t<Nullable.t<string>> like Present(Null) is matched as Null which might cause problems. Maybe not a big problem since it wasn't working before as well. But to make it work correctly and improve DX I think that @unboxed types should collapse like Nullable.t<Nullable.t<string>>->Nullable.t<string>

So maybe we should recover the @cristianoc's idea from some time ago? https://forum.rescript-lang.org/t/rfc-automatic-optional-chaining/3791/17?u=dzakh

That idea amounts to accepting that nested nullable is the same as nullable.
One can add a convenience function to that effect.

Even if pattern matching can be used, I still think having boolean-returning convenience functions as in this PR are useful because they are easily discoverable and can sometimes be used for more concise code than pattern matching. I don't have my code in front of me but know I have often used Option.isNone and Option.isSome even though I could use pattern matching for that.

yeah I agree, those utility functions can come handy from time to time (eg as a parameter of a filter function).